deref_patterns: support string and byte string literals in explicit deref!("...") patterns
#140028
+304
−38
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Specifically, this allows string literal patterns to be used where a `str` is expected when `deref_patterns` is enabled.
Specifically, this allows byte string literal patterns to be used where a `[u8]` or `[u8;N]` is expected when `deref_patterns` is enabled.
rustbot
added
S-waiting-on-review
|
Some changes occurred in match lowering cc @Nadrieril Some changes occurred in match checking cc @Nadrieril |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When
deref_patternsis enabled, this allows string literal patterns to be used wherestris expected and byte string literal patterns to be used where[u8]or[u8; N]is expected. This lets them be used in explicitderef!("...")patterns to match onString,Box<str>,Vec<u8>,Box<[u8;N]>, etc. (as well as to match on slices and arrays obtained through other means). Implementation-wise, this follows up on #138992: similar to how byte string literals matching on&[u8]is implemented, this changes the type of the patterns as determined by HIR typeck, which informs const-to-pat on how to translate them to THIR (though strings needed a bit of extra work since we need references to call<str as PartialEq>::eqin the MIR lowering for string equality tests).This PR does not add support for implicit deref pattern syntax (e.g.
"..."matching onString, asstring_deref_patternsallows). I have that implemented locally, but I'm saving it for a follow-up PR1.This also does not add support for using named or associated constants of type
&strwherestris expected (nor likewise with named byte string constants). It'd be possible to add that if there's an appetite for it, but I figure it's simplest to start with literals.This is gated by the
deref_patternsfeature since it's motivated by deref patterns. That said, its impact reaches outside of deref patterns; it may warrant a separate experiment and feature gate, particularly factoring in the follow-up1. Even without deref patterns, I think there's probably motivation for these changes.The update to the unstable book added by this will conflict with #140022, so they shouldn't be merged at the same time.
Tracking issue for deref patterns: #87121
r? @oli-obk
cc @Nadrieril
Footnotes
The piece missing from this PR to support implicit deref pattern syntax is to allow string literal patterns to implicitly dereference their scrutinees before matching (see resolve how to handle constants and default binding modes #44849). As a consequence, it also makes examples like the one in that issue work (though it's still gated by
deref_patterns). I can provide more information on how I've implemented it or open a draft if it'd help in reviewing this PR. ↩ ↩2